ebab7d0da53c51438720d60c6e2e467c - /page/wikibook/entry.mu

Micron Document

Livres et Wikis | Archives | Info

🔍Search

Java bytecode

23.1 KB · ⇊ 8 parts · ⤓ Micron 23.1 KB · ⤓ HTML 57.2 KB

layout: Wide · Narrow · Centered

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

top

Java bytecode is the instruction set of the Java virtual machine (JVM),

the language to which Java and other JVM-compatible source code is

compiled.cite-ref-oracle-jvm-spec-1-0[1] Each instruction is represented by a single byte, hence the

name bytecode, making it a compact form of data.cite-ref-jvm-book-2-0[2]

Due to the nature of bytecode, a Java bytecode program is runnable on

any machine with a compatible JVM, without the lengthy process of

compiling from source code.

Java bytecode is used at runtime either interpreted by a JVM or compiled

to machine code via just-in-time (JIT) compilation and run as a native

application.

As Java bytecode is designed for a cross-platform compatibility and

security, a Java bytecode application tends to run consistently across

various hardware and software configurations.cite-ref-3[3]

Contents

• Relation to Java

• Instruction set architecture

• Instruction set

• Example

• Generation

• Execution

• Support for dynamic languages

• See also

• References

• External links

Relation to Java

In general, a Java programmer does not need to understand Java bytecode

or even be aware of it. However, as suggested in the IBM developerWorks

journal, "Understanding bytecode and what bytecode is likely to be

generated by a Java compiler helps the Java programmer in the same way

that knowledge of assembly helps the C or C++ programmer."cite-ref-4[4]

Instruction set architecture

The bytecode comprises various instruction types, including data

manipulation, control transfer, object creation and manipulation, and

method invocation, all integral to Java's object-oriented programming

model.cite-ref-oracle-jvm-spec-1-1[1]

The JVM is both a stack machine and a register machine. Each frame for a

method call has an "operand stack" and an array of "local variables".cite-ref-jvm-5-0[5]

cite-ref-jvm-book-2-1[2] The operand stack is used for passing operands to computations and

for receiving the return value of a called method, while local variables

serve the same purpose as registers and are also used to pass method

arguments. The maximum size of the operand stack and local variable

array, computed by the compiler, is part of the attributes of each

method.cite-ref-jvm-5-1[5] Each can be independently sized from 0 to 65535 values, where

each value is 32 bits. long and double types, which are 64 bits, take up

two consecutive local variablescite-ref-jvm-5-2[5] (which need not be 64-bit aligned in

the local variables array) or one value in the operand stack (but are

counted as two units in the depth of the stack).cite-ref-jvm-5-3[5]

Instruction set

Each bytecode is composed of one byte that represents the opcode, along

with zero or more bytes for operands.cite-ref-jvm-5-4[5]

Of the 256 possible byte-long opcodes, as of 2015, 202 are in use

(~79%), 51 are reserved for future use (~20%), and 3 instructions (~1%)

are permanently reserved for JVM implementations to use.cite-ref-jvm-5-5[5] Two of these

(impdep1 and impdep2) are to provide traps for implementation-specific

software and hardware, respectively. The third is used for debuggers to

implement breakpoints.

Instructions fall into a number of broad groups:

• Load and store (e.g. aload_0, istore)

• Arithmetic and logic (e.g. ladd, fcmpl)

• Type conversion (e.g. i2b, d2i)

• Object creation and manipulation (new, putfield)

• Operand stack management (e.g. swap, dup2)

• Control transfer (e.g. ifeq, goto)

• Method invocation and return (e.g. invokespecial, areturn)

There are also a few instructions for a number of more specialized tasks

such as exception throwing, synchronization, etc.

Many instructions have prefixes and/or suffixes referring to the types

of operands they operate on.cite-ref-jvm-5-6[5] These are as follows:

| Prefix/suffix | Operand type |

|---|---|

| i | integer |

| l | long |

| s | short |

| b | byte |

| c | character |

| f | float |

| d | double |

| a | reference |

For example, iadd will add two integers, while dadd will add two

doubles. The const, load, and store instructions may also take a suffix

of the form _n, where n is a number from 0–3 for load and store. The

maximum n for const differs by type.

The const instructions push a value of the specified type onto the

stack. For example, iconst_5 will push an integer (32 bit value) with

the value 5 onto the stack, while dconst_1 will push a double (64 bit

floating point value) with the value 1 onto the stack. There is also an

aconst_null, which pushes a null reference. The n for the load and store

instructions specifies the index in the local variable array to load

from or store to. The aload_0 instruction pushes the object in local

variable 0 onto the stack (this is usually the this object). istore_1

stores the integer on the top of the stack into local variable 1. For

local variables beyond 3 the suffix is dropped and operands must be

used.

Example

Consider the following Java code:

outer:

for (int i = 2; i < 1000; i++) {

for (int j = 2; j < i; j++) {

if (i % j == 0)

continue outer;

}

System.out.println(i);

}

A Java compiler might translate the Java code above into bytecode as

follows, assuming the above was put in a method:

0: iconst_2

1: istore_1

2: iload_1

3: sipush 1000

6: if_icmpge 44

9: iconst_2

10: istore_2

11: iload_2

12: iload_1

13: if_icmpge 31

16: iload_1

17: iload_2

18: irem

19: ifne 25

22: goto 38

25: iinc 2, 1

28: goto 11

31: getstatic #84; // Field java/lang/System.out:Ljava/io/PrintStream;

34: iload_1

35: invokevirtual #85; // Method java/io/PrintStream.println:(I)V

38: iinc 1, 1

41: goto 2

44: return

Generation

The most common language targeting Java virtual machine by producing

Java bytecode is Java. Originally only one compiler existed, the javac

compiler from Sun Microsystems, which compiles Java source code to Java

bytecode; but because all the specifications for Java bytecode are now

available, other parties have supplied compilers that produce Java

bytecode. Examples of other compilers include:

• Eclipse compiler for Java (ECJ)

• Jikes, compiles from Java to Java bytecode (developed by IBM,

implemented in C++)

• Espresso, compiles from Java to Java bytecode (Java 1.0 only)

• GNU Compiler for Java (GCJ), compiles from Java to Java bytecode; it

can also compile to native machine code and was part of the

GNU Compiler Collection (GCC) up until version 6.

Some projects provide Java assemblers to enable writing Java bytecode by

hand. Assembly code may be also generated by machine, for example by a

compiler targeting a Java virtual machine. Notable Java assemblers

include:

• Jasmin, takes text descriptions for Java classes, written in a simple

assembly-like syntax using Java virtual machine instruction set and

generates a Java class filecite-ref-6[6]

• Jamaica, a macro assembly language for the Java virtual machine. Java

syntax is used for class or interface definition. Method bodies are

specified using bytecode instructions.cite-ref-7[7]

• Krakatau Bytecode Tools, currently contains three tools: a decompiler

and disassembler for Java classfiles and an assembler to create

classfiles.cite-ref-8[8]

• Lilac, an assembler and disassembler for the Java virtual machine.cite-ref-9[9]

Others have developed compilers, for different programming languages, to

target the Java virtual machine, such as:

• ColdFusion

• JRuby and Jython, two scripting languages based on Ruby and Python

• Apache Groovy, optionally typed and dynamic general-purpose language,

with static-typing and static compilation capabilities

• Scala, a type-safe general-purpose programming language supporting

object-oriented and functional programming

• JGNAT and AppletMagic, compile from the language Ada to Java bytecode

• C to Java byte-code compilers

• Clojure, a functional, immutable, general-purpose programming language

in the Lisp family with a strong emphasis on concurrency

• Kawa, an implementation of the Scheme programming language, also a

dialect of Lisp.

• MIDletPascal

• JavaFX Script code is compiled to Java bytecode

• Kotlin, a statically-typed general-purpose programming language with

type inference

• Object Pascal source code is compiled to Java bytecode using the

Free Pascal 3.0+ compiler.cite-ref-10[10]cite-ref-11[11]

Execution

There are several Java virtual machines available today to execute Java

bytecode, both free and commercial products. If executing bytecode in a

virtual machine is undesirable, a developer can also compile Java source

code or bytecode directly to native machine code with tools such as the

GNU Compiler for Java (GCJ). Some processors can execute Java bytecode

natively. Such processors are termed Java processors.

Support for dynamic languages

The Java virtual machine provides some support for

dynamically typed languages. Most of the extant JVM instruction set is

statically typed - in the sense that method calls have their signatures

type-checked at compile time, without a mechanism to defer this decision

to run time, or to choose the method dispatch by an alternative

approach.cite-ref-12[12]

JSR 292 (Supporting Dynamically Typed Languages on the Java

Platform)cite-ref-13[13] added a new invokedynamic instruction at the JVM level, to

allow method invocation relying on dynamic type checking (instead of the

extant statically type-checked invokevirtual instruction). The

Da Vinci Machine is a prototype virtual machine implementation that

hosts JVM extensions aimed at supporting dynamic languages. All JVMs

supporting JSE 7 also include the invokedynamic opcode.